[レポート]Supercell – Scaling Mobile Games #reinvent #GAM301

タケダノです。

クラッシュ＆クラン、クラッシュ＆ロワイヤルで有名なSupercellの話を聞いてきました。

 

概要

In this session, learn how Supercell architected its analytics pipeline on AWS. We dive deep into how Supercell leverages Amazon Elastic Compute Cloud (Amazon EC2), Amazon Kinesis, Amazon Simple Storage Service (Amazon S3), Amazon EMR, and Spark to ingest, process, store, and query petabytes of data. We also dive deep into how Supercell's games are architected to accommodate scaling and failure recovery. We explain how Supercell's teams are organized into small and independent cells and how this affects the technology choices they make to produce value and agility in the development process.

 

スピーカー

Heikki Verta - Services Team Lead, Supercell

 

内容

最初にゲーム産業で働いている人を挙手で確認。⇒半分くらいでした。

元々はサーバーサイドのエンジニアでした。

 

今日のアウトラインです

• 　Supercellのチーム構成と文化
• 　ゲームのスケーリング
• 　スケーリングの分析

 

まず会社の紹介をします。

2003年に設立したヘルシンキの会社です。

 

チャレンジしてきたこと

５つのゲームで

1億人のアクティブユーザーがいて

4メガのピーク並列処理があり

EC2のインスタンスは6000立ち上げて

データベースも300程用意して

複数のリージョンに渡って展開してきた。

さらに250人の会社で、20人が1つのゲームチームで3人がサーバー開発者です。

 

 

Supercellのチーム構成と文化

「ベストチームがベストゲームを作る」

というのが信条です。

 

・小さなチーム構成をしており

・トップダウンでは無くボトムアップ型

・チームで独立心があり、責任も伴います。

 

アジャイル型です

 

AWSアーキテクチャに対するSupercellの企業文化の意味合い

・それぞれのチームがAWSアカウントを持っています。

・オペレーションチームが分離しているわけではありません

・チームはそれぞれがテックスタック（マーケティング一連の流れ）を選ぶ事が出来ます。

・我々はAWSのサービスを上手く使うことで運営の負荷を減らします。

 

評価はアナリティクスやマシンラーニングを使っています

 

ゲームのスケーリング

伝統的なクライアント-サーバー型アーキテクチャ

サーバーはJavaで実装され、データベースはMySQLです。

 

それが今はEC2インスタンス上でサーバーを稼働させています。

スケーリングアップでは無く、スケーリングアウトです。

マイクロサービス・アーキテクチャが大事になってきました。

ゲームはサービスごとに分割されるようになりました。

サービス毎に異なるインスタンスで実行されるのです。

 

Scaling out

Amazon EC2によるインスタンスのオートスケールも使いながらZookeeperも別の役割を持ちながらEC2を監視しています。

それぞれのインスタンスでオートスケールコントロールがなされているけれど、もう一方にZookeeperがいます。

黄色はインスタンスの数で、スケールの様子を表しています。

 

Scaling out database layer

データベースのレイヤーは複数のシャードに分割されています。

新しいシャー度にスケールアウトするための操作は手動で行われます。

またシャードはゲームに影響を与えません。

Database failure recovery

MySQLのマスターノードが破損するとゲームのシャードが破損します。

データベースの破損は未だに手動で対応しています。

新作”Brawl Stars”ではAmazon Auroraを使って緩和しています。

Scaling Analytics                                                                          

Supercellのデータカルチャー

これは企業文化の一つです

データサイエンティストが、それぞれのチームにいます。

分析がヒットするゲームを作り出すわけではありません。ただデータ分析によって改良は出来ます。

純度の高いデータが社内にあります。

 

数字で見る分析

・1日に5 TBのデータ量

・15B atomic “rows” またはイベント

データウェアハウスの合計サイズは4PBに届くほど

 

Analytics timeline

そのときごとに進化しています。

Event pipeline, 2012

精度を上げたいと思った

 

Event pipeline 2013

プロトコルをUDPに変更し、最終的にS3に保存するようにした

精度は上がった

 

イベントパイプラインの良し悪し

＋シンプルになる

＋より詳細となり単なるデータベースではなくなる

 

－リアルタイムアクセスではなくなる

－ローカルディスクが破損したり一杯になったりするとデータがロスしてしまう

－データ消費がAmazon S3からのみとなる

 

2013末にKinesisが登場した

とても人気があるデータソリューション

LZOをつかってS3にデータ保存

 

Benefits of streaming pipeline

データがローカルの破損から守られる

リアルタイムでデータにアクセス出来る

データ消費に複数の方法がある

 

Amazon Kinesis dispatching

・挑戦したこと

メインストリームが巨大だった（ストリーム毎に200シャード、データ量が100MB/s）

ストリームが複数のイベントタイプを含んでいた

全てのクライアントが、全てのイベントタイプに興味があるとは限らない

・解決方法

メインストリームをアプリケーションの特定のストリームに分割

アプリケーションの特定のストリームが、１つのイベントサブセットを含むようにした

 

ETL and data warehouse in 2013

S3 から Verticaに入れる仕組みだった

・挑戦したこと

クラスターへのスパイキーな負荷

ETL中にクエリが遅くなる

スケールアップまたはダウンにはかなりの労力がかかる

ストレージとコンピュートが密に結びついている

大きなデータベースクラスターにも限界がある

 

・目標

Verticaのデータ量を制限する

コンピューティングをストレージから分離する

ETL処理とクエリを分離する

データの真実の単一のソースを維持する

クラウドの柔軟性を活用してリソースの使用を最適化する

 

・計画

Amazon S3を真実の単一のソースとする

寄せ集めて保存されたデータ

ETLのためのAmazon EMR

結果のためだけのVertica（アカウント、集計、KPIなど）

 

いつも失敗する事を想定している

 

 

現在のアプローチによる利点

コンピュートとストレージの分離

Amazon EMRが非常に大きなデータセットに拡張される

ETLワークロード用の専用クラスター、および一時クラスター

データサイエンティストにとって親しみのある環境

 

さいごに

大事な事はスケーリングと破損データの回復

コンピュートとストレージは分離

大事な事に焦点を当てる

スキーマをどうやって定義するか考える

データ警察はいらない

 

企業文化として大切なのはチームがそれぞれ独立していること

Supercellにとって大事なのは独立したチームがいること

Supercellにとって最も挑戦的な事は独立したチームであること

そして利益はコストを上回るということ

 

いかがでしたか。

Supercellがパイプラインを構築するのに、その都度苦労してきた感じが伝わってきました。

一緒にパイプラインを考えたいと思ったゲーム会社の方は是非クラスメソッドへご連絡ください。

担当者が誠意を持って対応をさせて頂きます。